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I.  IMTaODOCTIOS 


This  thesis  is  an  attempt  to  understand  the  software 
cost  estimating  process  as  viewed  by  a  program  manager 
during  the  early  phases  of  system  development. 

Software  cost  estimators  have  problems  because  of  their 
inability  to  estimate  the  size  of  new  programs. 
His  tori  call  y- based  methods  are  difficult  to  use  because  the 
estimator  is  unable  to  assess  skills,  tools,  complexity,  and 
environment  of  past  developments  and  of  the  new  software. 
The  results  are  severe  cost  overruns,  schedule  slippage,  and 
lack  of  credibility.  [Ref.  1] 

In  software  estimating  models,  software  size  is  the  key 
parameter  influencing  cost.  All  the  proven  estimating  tech¬ 
niques  begin  with  an  estimate  of  the  size  of  the  software 
package  and  then  at  various  levels  of  sophistication  produce 
an  estimate  of  cost  or  time  based  on  size  and  calculated  or 
derived  productivity  factors. 

A  quack,  reliable  estimate  of  size  could  provide  a 
better  cost  estimate  for  planning  purposes.  The  program 
manager's  concern  is  time,  cost,  and  performance  of  the 
total  system.  He  needs  to  present  this  information  to  higher 
DOD  management  levels  during  the  early  planning  phase. 

This  paper  rs  an  investigation  of  ways  in  which  an  esti¬ 
mator  may  be  able  to  estimate  the  size  of  a  new  project, 
based  on  an  existing  data  base  of  close  to  1,000  systems. 
Breakouts  have  been  made  of  that  data  base  by  application 
type  and  the  average  size  and  the  standard  deviation  of  each 
of  these  applications  is  calculated.  In  the  early  phase  of 
system  development,  a  reasonable  goal  would  be  to  estimate 
time  within  15  percent  and  effort  within  30  percent  of 
actual. 


The  program  manager  should  have  a  detailed  understanding 
of  the  process  that  developed  the  cost  estimate  and  should 
have  some  traceability  to  the  variance  or  sensitivity  of  the 
estimating  component.  The  use  of  automated  software  models 
for  estimating  has  become  popular  in  industry  and  .  DOD. 
Program  managers  can  compare  different  models  for  alterna¬ 
tive  estimates. 

All  the  variables  of  the  software  equation  are  subject 
to  some  degree  of  uncertainty  and  the  program  manager  must 
have  a  means  of  taking  this  into  account  in  an  effort  to 
development  risk  profiles.  Putnam  £  Ref .  2]  suggests  that 
risk  analysis  is  probably  the  most  important  aspect  of  any 
software  system  analysis.  In  an  uncertain  process,  risk 
analysis  measures  that  uncertainty.  This  leads  to  strat¬ 
egies  tc  minimize  risk.  The  program  manager  should  perform 
risk  analysis  and  determine  the  probability  of  meeting 
schedule/cost . 

This  paper  uses  SLIM  (Software  Life-cycle  Management)  . 
The  SLIM  model  uses  some  of  the  most  powerful  tools  of  anal¬ 
ysis  available  today  —  linear  programming,  Monte  Carlo 
simulation,  and  algorithms  from  the  PERT  methodology  —  to 
produce  the  best  possible  solution  to  the  software  esti¬ 
mating  problem.  [Ref.  1] 

The  program  manager  predicts  and  controls  schedule  and 
costs.  It  is  important  for  the  program  manager  to  recognize 
potential  problems  early  and  take  effective  corrective 
action. 
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II.  SOFTWARE  LIFE-CYCLE  AND  DEVELOPMENT  PBOCESS 

The  software  life-cycle  nay  be  said  to  start  in  the 
perception  of  a  need  and  to  terminate  when  t-he  system  is 
retired  as  obsolete.  The  program  manager  has  the  responsi¬ 
bility  from  start  to  end  for  the  project.  The  program 
manager  must  understand  the  software  life-cycle  and  its 
development  process.  A  lack  of  understanding  of  the  process 
of  software  development  (activities,  phases,  and  milestones) 
causes  a  poor  estimate.  The  software  development  process 
can  be  subdivided  into  seguential  and  overlapping  phases. 

Figure  2.  1  [Ref.  2]  depicts  the  total  system  milestones 
in  relationship  with  four  software  cost  models  considered. 
The  DOD  subdivides  the  life  cycle  of  an  automated  informa¬ 
tion  system  into  five  broad  phases:  [Ref.  3]  Mission 

Analysis  Project  Initiation,  Concept  Development,  Definition 
Design,  system  Development,  Deployment  Operation. 

Putnam  [fief.  4]  divides  it  as:  Systems  definition. 

Functional  design  specification.  Development  (design  and 
coding,  test  and  validation).  Operation  and  maintenance. 
The  development  process  is  divided  as  follows. 

PDR  -  preliminary  Design  Review.  This  is  the  earliest 
time  that  a  formal  review  of  the  functional  design  specifi¬ 
cations  car.  be  expected  to  be  satisfactory  enough  tc 
continue  into  the  next  phase  of  development.  Functional 
design  and  (high  level)  system  engineering  is  essentially 
complet  e. 

CD R  -  Critical  Design  Review.  This  is  a  review  of  the 
detailed  logic  design  for  each  element  of  system.  The 
design  consists  of  flow  charts,  HIPO1  diagrams.  Pseudo-code 

1  HI FO  (fiierarchy-Prccess-Input-Out put)  was  developed  at 
IBM  as  design  representation  schemes  for  top-down  software 
development  and  contained  a  visual  table  of  contents,  a  set 
of  overview  overview  diagrams,  and  a  set  of  detail  diagrams. 
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Figure  2.1  Software  Life-Cycle. 


logic,  or  equivalent.  It  is  held  when  design  and  coding  are 
separated  by  management  decision  as  by  MIL  STD  (military 
standards).  Coding  cannot  start  until  after  a  successful 
CDR  under  this  philosophy.  There  must  be  sufficient  design 
to  start  coding. 

FCC  -  First  Code  Complete.  In  a  top-down,  structured 
design  and  coding  environment,  FCC  is  the  time  at  which  all 
the  units  of  code  have  been  written,  the  units  have  been 
peer  and  management  checked,  successfully  compiled  and  run 
as  units,  and  thought  to  be  satisfactory  end  product  code. 
It  is  then  entered  into  a  library  of  completed  code.  (Note: 
coding  will  continue  thereafter  as  rework  of  these  modules.) 


SIT  -  Systems  Integration  Test.  This  is  the  earliest 
time  that  all  elements  and  subsystems  have  been  pat  together 
and  the  system  can  work  together  as  a  complete  integrated 
package  and  can  demonstrate  that  in  a  formal  system  test. 

DOST-  User  Oriented  System  Test.  Following  correction  of 
deficiencies  resulting  from  SIT,  DOST  is  the  first  time  that 
a  test  of  the  system  in  a  full  user  environment  —  target 
machine  and  operating  system,  real  data,  real  operating 
conditions  —  can  be  conducted. 

IOC  -  Initial  Operational  Capability  or  start  of  instal¬ 
lation,  depending  on  the  environment.  This  is  a  careful, 
tentative  first  use  under  rigid  control.  Often  this  is  a 
first  site  installation  in  a  live  environment  with  antici¬ 
pated  later  multi-site  deployment,  or  the  start  of  operation 
in  parallel  with  the  predecessor  system  in  a  single  site 
replacement  environment. 

FOC  -  Full  Operational  Capability.  Here  the  system 
meets  specified  quality  standards  sufficiently  nexl  that 
organizations  will  use  it  in  everyday  routine  mission  opera¬ 
tions.  (In  SLIM ,  that  is  a  95  percent  reliability  level; 
calibration  and  technology  factors  are  normalized  to  this 
reliability  level.) 

Boehm  [Ref.  5]  divides  the  cycle  into  feasibility,  plans 
and  requirements,  product  design,  programming,  integration 
and  test,  ana  maintenance.  The  primary  emphasis  of  his 
C0C0M02  model  is  on  the  development  portion  of  the  life- 
cycle  which  CCCOMO  defines  as  starting  •*  at  the  beginning  of 
the  product  design  phase  and  ending  at  the  end  of  the  soft¬ 
ware  integration  and  test  phase  ".  [Ref.  5] 


constructive  CGst  Model,  a  hierarchy  of  three  increas¬ 
ingly  detailed  models  (  basic,  intermediate.  detail)  which 
range  from  a  single  mac ro- estimation  scaling  model  as  a 
function  of  product  size  to  a  micro-estimation  model  with  a 
three-level  work  breakdown  structure  and  a  set  of  phase- 
sensitive  multipliers  for  each  cost  driver  attribute. 


The  PBICE-S  software  model  is  one  of  the  family  of  RCA 
cost  predicting  sodels.  PBICE-S  divides  the  software  devel¬ 
opment  cycle  into  three  phases:  design,  implementation,  and 
test  and  integration. 

The  guestion  facing  the  program  manager  is  what  to 
invest  in  and  what  is  its  payoff.  Boehm  [  Ref .  5]  developed 
a  value-of- information  guideline  with  the  following  five 
con  di  ti  cns : 

1.  There  exist  attractive  alternatives  whose  payoff  varies 
greatly,  depending  on  some  critical  state  of  nature. 

2.  The  critical  states  of  nature  have  an  appreciable 
probability  of  occuring. 

3.  The  investigations  have  a  high  probability  of 
accurately  identifying  the  occurrence  of  critical 
states  of  nature. 

4.  The  required  cost  and  schedule  of  the  investigations 
do  not  overly  curtail  their  net  value. 

5.  There  exist  significant  side  benefits  derived  from 
performing  the  investigations. 

The  major  difficulty  with  these  guidelines  is  deter¬ 
mining  what  are  the  critical  states  of  nature.  Boehm  implies 
some  of  these  states  in  his  definition  of  feasibility  phase 
and  plans  and  requirements  phase  [Ref.  5]: 

Feasibility  phase;  How  much  should  we  invest  in  informa¬ 
tion  system  (user  questionnaires  and  interview  ,  current- 
system  analysis,  workload  characterizations,  simulations, 
scenarios,  prototypes)  in  order  that  we  converge  on  an 
appropriate  definition  and  concept  of  operation  for  the 
system  we  plan  to  implement? 

Plans  and  requirements  phase;  How  rigorously  should  we 
specify  requirements?  How  much  should  we  invest  in  require¬ 
ments  validation  activities(  automated  completeness,  consis¬ 
tency,  and  traceability  checks,  analytic  models, 
simulations,  prototypes)  before  proceeding  to  design  and 


develop  a  software  system?  It  is  important  for  the  program 
manager  to  know  the  early  phases  of  system  development. 

Boehm  [  Ref.  6]  points  out  the  uncertainty  of  cost  esti¬ 
mation  during  the  early  project  phase.  Fig  2.2  shows  the 
accuracy  within  which  software  cost  estimation  can  be  made, 
as  a  function  of  the  software  life-cycle  phase  ,or  of  the 
level  of  knowledge  we  have  of  what  the  software  is  intended 
to  do.  At  the  beginning  of  the  feasibility  phase,  the  rela¬ 
tive  range  of  software  cost  estimates  is  roughly  a  factor  of  . 
four3  on  either  the  high  or  low  side  which  is  not  surprising 
based  on  the  limited  knowledge  available  at  this  point.  The 
estimation  uncertainty  is  reduced  to  from  .5  to  2  after  the 
concept  of  operation  has  been  defined.  After  completion  of  a 
requirement  specification,  the  estimation  range  is  .67  to 
1.5.  Gradually,  the  estimation  range  becomes  smaller  until 
we  finally  arrive  at  acceptance. 

Fairley's  [Ref.  7]  suggested  life-cycle  approach  divides 
into  four  models:  The  phased,  model,  cost  model,  prototype 

life-cycle  model,  and  successive  versions  model.  Costs 
incurred  within  each  phase  include  the  cost  of  performin'? 
the  process  and  preparing  the  products  for  that  phase,  plus 
the  cost  of  verifying  that  the  products  of  the  present  phase 
are  complete  and  consistent  witn  respect  tc  all  previous 
phases.  Fairley  also  suggests  there  art  some  reasons  for 
developing  a  prototype:  (1)  to  illustrate  input  data 

formats,  message,  reports  ,  and  interactive  dialogues  for 
the  customer;  (2)  to  explore  technical  issues  in  the 
proposed  product;  and  (3)  in  situations  where  the  phased 
model  or  analysis  ->  design  ->  implementation  is  not  appro¬ 
priate.  Product  development  by  the  method  of  successive 
versions  is  an  extension  of  prototyping  in  wnich  an  initial 
product  skeleton  is  refined  into  increasing  levels  of 


3The  ranges  are  intended  to  represent  80  percent  confi¬ 
dence  limits,  that  is  ,  "  within  a  factor  of  four  cn  either 
side,  83  percent  of  the  time." 
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Figure  2.2  Software  Cost  Estimation  Accuracy  vs.  Phase. 


capability. 

Putnam  [Eef.  8]  suggests  that  a  good  life  cycle  model 
should  possess  these  characteristics: 

1.  Consider  all  activities  and  phases. 

2.  Relate  management  parameters  to  management 
re  sponsibilities. 

3.  Be  adaptive  to  actual  project  data  and  reguirements 
changes  (  i.e.  must  be  time-varying  or  dynamic) 

4.  provide  engineering  accuracy. 

5.  Provide  sensitivity  profiles. 

6.  Be  phenomenologically  based. 

7.  Relate  produce  to  resource  consumption  (both  statically 
and  dynamically)  the  technology  being  applied. 

8.  Be  capable  of  future  growth. 

9.  Be  able  to  adequately  treat  known  and  future  system 
types  and  development  environments. 
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Software  life  cycle  and  development  processes  offer  a 
structured  means  for  planning,  developing,  and  controlling 
the  software  project.  Boehm  [Bef.  9]  suggests  that  the 
tradeoffs  between  lower  development  costs  and  lower  life 
cycle  costs  are  characterized  by  the  modern  programming 
practice  and  required  reliability  cost  estimating  relation¬ 
ships  for  software  development  and  maintenance.  The  program 
manager  oust  understand  the  software  life-cycle  and  develop¬ 
ment  process  cf  multiple  models  and  compare  with  DOD  life- 
cycle.  The  program  manager  must  predict  and  control  schedule 
and  costs.  Also  the  program  manager  must  recognize  poten¬ 
tial  problems  early  and  taJce  effective  corrective  action.  It 


III.  BSTIHATIHG 


AMD  COST  ATTBIBOTZ  FACTORS 


In  order  for  the  program  manager  and  his  support  team 
to  evaluate  a  software  cost  proposal,  they  must  have  a 
detailed  understanding  of  the  process  that  developed  the 
cost  estimate  and  should  have  some  traceability  to  the  vari¬ 
ances  or  sensitivity  of  the  estimating  components. 

The  object  of  software  cost  estimation  is  to  determine 
what  resources  (manpower,  computer  time,  and  elapsed  time) 
will  be  neeaed  to  produce  the  software  associated  with  the 
project.  Stanley  [Ref.  10]  listed  some  reasons  for  not 
obtaining  a  good  estimate  as: 

1.  A  lack  of  understanding  of  the  process  of  software 
de  velopmen  t. 

2.  A  lack  of  understanding  of  the  effects  of  various 
technical  and  management  constraints. 

3.  A  view  of  that  each  project  is  unique,  whicn 
inhibits  project  to  project  comparisons. 

4.  A  lack  of  historical  data  against  which  the  model 
can  be  checked  and  for  calibration. 

Boehm  [Ref.  5]  suggests  that  a  good  software  model 
should  possess  the  following  characteristics: 

1.  Definition:  Can  you  tell  what  it  is  estimating? 

Will  different  people  give  similar  factor  rating? 

2.  Fidelity:  Are  the  actuals  close  tc  the  estimates? 

3.  Detail:  Does  it  give  (accurate)  phase  and  activity 
br  eakdowns? 

4.  Constructiveness:  Can  you  tell  why  it  gives  the 
estimates  it  does?  Does  it  help  ycu  understand  the 
software  job? 

5.  Objectivity:  Is  it  hard  to  jigger  the  model  to  get 
any  result  you  want? 

6.  Stability:  Do  small  input  changes  produce  small  output 


ch  anges? 

7.  Scope:  Does  the  model  cover  your  class  of  software 
project? 

&.  Easy  to  use:  Are  the  model  inputs,  and  outputs  easy  to 
understand  and  specify? 

9.  Prospectiveness:  Does  it  depend  on  information  not 
known  until  later? 

10.  Parsimony:  Does  it  use  redundant  or  unnecessary 
factors? 

11.  Availability:  Can  I  get  access  to  the  model? 

The  program  manager  compares  various  cost  models  for 
alternative  estimates.  The  model  should  allow  for  the  use 
of  historic  data  in  calibration  for  a  particular  organiza¬ 
tion  and  type  of  software.  A  good  software  cost  estimation 
model  should  cover  software  engineering  issues  which  arise 
throughout  the  software  life  cycle. 

A.  TECHNIQUES 

According  tc  Stanley  fRef.  10],  most  cost  models  use  one 
or  both  of  the  following  equations.  The  first  is  called  the 
cost  equation: 

b 

E  =  a  *  S 

where  E  =  effort  needed,  s  =  size  of  program  is  terms  of 
some  measure  of  lines  of  code  and  a  and  b  are  chosen  by 
curve  fitting  on  a  historical  database.  Different  values  of 
a  and  b  are  appropriate  to  different  organizations,  project 
types,  units  of  measurement  of  E  and  S,  and  items  include! 
in  the  the  estimates. 

The  second  equation  is  called  the  general  summing 
eguatio  n: 

n 

3  =  Z  af  =af  +af  ♦  .......  ♦  a  f 

i=1  i  i  11  22  nn 
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where  the  a-  are  input  parameters  derived  from  the  descrip¬ 
tion  of  software  characteristics  and  the  characteristics  of 
the  development  environment,  and  the  value  of  f;  are  chosen 
by  curve  fitting  on  a  suitable  historic  database.  Table  1 
[Ref.  7]  shows  a  comparison  of  effort  and  development  time 
eguations  according  to  software  size.  Some  models  provide 
equations  to  estimate  total  man  months  of  effort,  HM,  in 
terms  of  the  number  of  thousands  of  delivered  source 
instructions,  KDSI.  Also  the  development  time  for  software 
project,  TD2V,  measured  in  terms  of  MM.  A  software  project's 
cost  can  be  obtained  by  multiplying  the  effort  in  man  months 
by  the  cost  per  nan  month. 


TABLE  1 

COMPARISON  OP 

EFFORT  AND  TINE  EQUATIONS  [p.ef.  7]  ] 

Effort  equation 

Development  time 

i 

Author 

MM  = 

TDEV  = 

5.2  (KDSI)  **0.9  1 

2.47  MM)  **0.35 

Walston 

4.9  (KDSI)  **0.98 

3.04  MM)  **0.36 

Nelson 

1.5  (KDSI)  **1.02 

4.38  MM)  **0.25 

Freburger 

2.4  (KDSI)  **1.05 

2.50  MM)  **0.38 

3oehm 

3.0  KDSI)  **1.12 

2.50  MM)  **0.35 

Boehm 

3.6  (KDSI)  **1.20 

2.50  MM)  **0.32 

Boehm 

1.  0  (KDSI)  **  1.40 

— 

Jones 

0.7  (KDSI)  **1.50 

— 

Halstead 

28  (KDSI)  **1.83 

Schnieder 

Thibodeau  [Ref.  11]  states  that  parametric  models  may  be 
divided  into  three  classes: 

1.  Regression  model:  The  parameters  to  be  estimated  are 
mathematically  related  tc  a  set  of  input  parameters. 

The  parameters  of  the  hypothesized  relationships  are 
arrived  at  by  statistical  analysis  and  curve  fitting 
on  an  appropriate  historical  database. 

2.  Heuristic  models:  Here  observation  and  interpretation 
of  historic  data  are  combined  with  supposition  and 


experience. 

3.  Phenomenological  model:  This  is  based  on  a  hypothesis 
that  the  software  development  process  can  be  explained 
in  terms  of  some  more  widely  applicable  process  or 
idea. 

The  first  model  class  seems  tc  be  the  approach  used  in  most 
ccst  modeling.  This  class  includes  the  Aerospace,  Doty, 
Farr,  Zagorski,  and  Telecote  models.  The  second  model  class 
seems  to  be  the  type  used  in  preparing  a  proposal  where 
detailed  WBS  elements  are  prepared  and  summed  for  the  total 
cost.  The  Eoeing  and  PHICE  S  models  along  with  the  DOD 
MIC HO  Procedure  and  the  Wolverton  model  nave  been  termed 
heuristic.  An  example  of  the  last  class  is  the  Putna.t 
model.  [  Ref .  11] 

Stanley  [Hef.  10]  suggests  a  general  pattern  followed  by 
all  the  models: 

1.  Estimate  software  size 

2.  Convert  size  estimate  to  labor  estimate 

3.  Ad ]ust  estimate  for  special  project  characteristics 

4.  Divide  the  total  estimate  into  the  different  project 
ph  ases 

5.  Estimate  non- technical  labor  costs 

6.  Sum  the  cost 

.lost  models  start  from  an  estimate  of  project  size.  Some 
models  convert  from  size  to  labor,  others  go  directly  from 
size  to  money  estimates.  The  effective  estimate  is  an 
adjustment  of  the  basic  estimate  intended  to  take  account  or 
any  special  project  characteristics  which  make  it  dissimilar 
to  the  pattern  absorbed  in  the  underlying  historic  database. 
Each  model  which  deals  with  a  project's  schedule  makes 
assumptions  about  the  allocation  of  effort  in  different 
project  phases. 


B.  SOBS  SPECIFIC  TECHNIQUES 


Fron  the  CSM*  data  base,  we  perform  curve  fitting  to  get 
the  relationship  of  software  size  versus  development  time 
and  effort  using  the  regression  method.  Despite  the  wide 
ranges,  the  development  time  and  effort  correlate  very  well 
with  the  number  of  source  statements.  Figure  3.1  shows 
size  versus  development  time  from  the  curve-fitting  method. 


Mixed  Application  Data  Base 

- - r!000 


Figure  3.1  QSH  Database  Software  Size  vs.  Development  Time 

To  estimate  software  size,  the  PERT5  method  is  suggested. 
The  PERT  equations  estimate  the  expected  size  (ES)  and  stan¬ 
dard  deviation  (  6  )  of  each  subsystem  as 

ES.=  (  a  ♦  4m  ♦  b  )  /  6  ,  (S  -  (b  -  a  )/6 

i  i  i  i  i  i  i 

where 


♦Quantitative  Software  Management,  Inc. 
5Program  Evaluation  and  Review  Technique. 


a  =  the  lowest  possible  size  ◦£  the  software  subsystem 

o.  =  the  nest  likely  size  of  the  subsystem 

b  =  the  highest  possible  size  of  the  subsystem 
i 

The  estimated  total  software  size  (S)  and  standard  deviation 
(^*S)  are  t hen 


This  PEBT  sizing  technique  requires  more  work  to  break  up 
the  software  into  subsystems  and  to  estimate  most  likely 
size  for  each  subsystem  as  well  as  to  eliminate  upper  and 
lower  limits.  PEBT  estimates  should  be  made  by  knowledge¬ 
able  software  designers,  preferably  those  who  will  do  the 
specific  work. 

C.  COST  ATTBIBOTE  FACTORS 

Stanley  [Ref.  10]  defines  two  major  area  of  software 
cost  drivers:  project  specific  factors  and  organization 

dependent  factors.  Eoehm  [Ref.  9]  identifies  five  factors 
which  closely  match  Stanley's.  Size  attributes,  program 
attributes  and  computer  attributes  fall  into  Stanley’s 
project  specific  factor.  Personnel  attrioutes  and  project 
attributes  fall  into  Stanley's  organization-dependent 
factors.  Holverton  [Ref.  12]  suggests  that  top-level  char¬ 
acteristics  are  parameters  which  can  be  classified  into 
software  structural  parameters  and  project  financial  parame¬ 
ters.  Soitware  structural  parameters  may  be  divided  size, 
program  attributes,  hardware  attributes,  project  attributes, 
environmental  attributes.  Project  financial  parameters  are 
divided  into  direct  labor  charges,  overnead,  other  direct 
charge,  general  and  administrative  expense,  and  fee. 
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Bruce  and  Pederson  [Hef.  13]  divide  cost  drivers  into 
four  categories;'  requirement  factors,  product  factors, 
process  factors,  and  resource  factors. 

1 .  Requirement  Factor 

Two  factors  that  can  have  a  major  impact  on  the 
ultimate  cost  of  a  software  product  are  (1)  the  quality  of 
the  specif ications  and  (2)  the  stability  of  tne  requirement. 

a.  Quality  of  Specifications 

A  good  definition  of  requirements  is  the  corner¬ 
stone  of  a  well-defined,  we  11- understood,  and  well-costed 
software  development.  Incomplete  requirement  definition  is  a 
major  cause  of  cost  overruns. 

b.  Stability  of  Requirements 

The  responsibility  of  the  project  manager  is  to 
understand  the  software  requirements  and  to  point  out  that 
changes  in  the  requirement  baseline  are  cnanges.  The 
project  manager  should  then  define  the  cost  and/or  schedule 
impact  so  that  the  change  can  be  given  a  fair  evaluation. 

2 -  Pro  duct  Factors 

a.  Software  Size 

A  favorite  measure  for  software  system  size  is 
lines  of  operational  code  or  deliverable  code.  Parametric 
cost  estimating  models  relate  cost  in  some  way  to  the  size 


estimat  e 


c.  Reliability 

Reliability  requirements  determine  the  through¬ 
ness  of  testing  needed  before  software  can  be  used  in  the 
intended  operational  environment.  There  are  four  major 
criteria  for  determining  the  reliability  of  software 
program.  It  must  (1)  provide  continuity  of  operation  under 
nonnominal  conditions;  (2)  utilize  uniform  design,  implemen¬ 
tation  techniques,  and  notation;  (3)  yield  the  required 
precision  in  calculations  and  outputs ;  and  (4)  be  imple¬ 
mented  in  an  understandable  manner. 

d.  External  Interface 

Especially  beware  of  special  purpose  hardware 
interfaces  and  sophisticated  user  interface. 

e.  Language  Requirement 

The  use  of  design  languages  has  been  shown  to 
help  decrease  the  time  reguired  in  programming  and  to 
provide  well-structured  and  documented  code. 

f.  Documentation  Requirement 

Beth  customer-specified  documentation  require¬ 
ments  and  documentation  reguired  by  the  project  management 
as  part  of  the  selected  development  approach  must  be 
considered. 

3 •  Process  Factors 

The  software  costing  factors  associated  with  the 
development  process,  such  as  management  structure,  manage¬ 
ment  controls,  development  methods,  tools,  use  of  available 
software,  and  data  base  methods. 
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Manage  men  t  Structure 


Management  structure  incorporates  the  effects  of 
various  company  policies  with  respect  to  allocating  costs 
for  certain  non-project  management  personnel  as  a  direct 
charge  to  projects. 

b.  Management  Control 

This  covers  the  cost  of  project  support  in  i.'cn 
areas  as  management  information  processing,  scheduliL’ 
support,  administrative  support,  and  clerical  support. 

c.  Development  Methods 

This  factor  attempts  to  guantify  the  impact  of 
various  development  methods.  The  development  methods  of 
interest  include  such  approaches  as  top-down  design  and 
testing,  structured  programming,  use  of  chief  programmer 
teams,  and  use  of  the  structured  walk-throughs. 

d.  Tcols 

The  program  manager  must  consider  how  the  soft¬ 
ware  will  be  developed,  tested,  and  maintained  and  what 
tools  will  be  needed  to  accomplish  these  tasks.  For  systems 
developed  for  large-scale  computer,  a  host  of  compiler,  data 
base  managers,  editors,  display  interface  package,  flow 
chart  package,  plot  package,  utility  routines,  and  test  data 
generation  tools  are  generally  available.  The  costs  associ¬ 
ated  with  tools  are  a  function  of  the  tool  complexity,  use, 
features,  and,  maturity. 

e.  Available  Software 

A  significant  reduction  in  project  can  be 
achieved  through  the  use  of  existing  software.  The  costs  of 
modifying  the  existing  software  can  then  be  determined 
sub  ject  ivel  y . 
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£.  Data  Base 

The  size,  complexity,  and  special  file  access 
requirements  for  the  data  base  are  extremely  important 
parameters  in  deriving  an  accurate  software  development 
estimate. 

4.  Besource  Factors 

Development  costs  for  a  given  software'  package  may 
vary  substantially,  depending  on  such  factors  as  experience 
of  available  people,  quality  of  project  staff,  and  avail¬ 
ability  of  development  computer  resources. 

a.  Number  of  People 

The  major  contributor  to  the  reduction  in 
productivity  associated  with  projects  that  require  larger 
staffs  is  the  increase  in  time  needed  for  communication 
between  people. 

b.  Experience  oi  People 

The  program  manager  must  consider  the  general 
level  of  experience  and  skill  required  for  various  project 
assignment  and  incorporate  appropriate  labor  rates  into  the 
estimat  e. 

c.  Personnel  Performance 

Since  software  development  is  an  analytical, 
sometimes  creative  activity  requiring  abstract  reasoning, 
individual  productivity  variations  are  to  be  expected. 
Productivity  assessment  is  extremely  important  because  cost 
estimation  generally  is  reduced  to  deriving  a  productivity 
figure  per  unit  of  effort  per  person  for  a  given  skill 
cat  ego r  y. 


d.  Availability  of  Computing  Besources 

For  batch  development  systems  there  is  a  linear 
relationship  between  turnaround  time  and  testing  costs.  For 
interactive  development  systems,  significant  development 
efficiencies  are  often  realized. 

e.  Suitability  of  Computing  Resources 

The  asymptotic  effect  on  development  costs  as 
the  hardware  speed  and  memory  size  constraints  are 
approached  has  been  demonstrated  in  batch,  real-time, 
airborne,  military,  and  commercial  system. 

f.  Elapsed  Time 

The  amount  of  calender  time  available  to  develop 
a  software  product  is  intimately  related  to  the  ultimate 
development  ccst.  Below  the  threshold,  the  increased  staff 
required  to  accomplish  the  job  in  a  shorter  period  has  the 
opposite  of  the  desired  effort. 

Table  2  [fief.  6]  shows  the  various  size,  program, 
computer,  personnel,  and  project  attributes  used  by  each 
model  tc  determine  software  costs. 

Numerous  factors  influence  the  cost  of  a  software 
development  project  and  each  should  be  evaluated  during  cost 
estimation  to  ensure  that  proper  weighting  is  applied  to  the 
cost  estimates.  Current  models  differ  in  the  factors  that 
are  required  as  specific  inputs.  Many  different  factors  may 
be  subsumed  in  a  single  parameter  in  some  models,  particu¬ 
larly  the  model  subjective  parameters.  The  program  manager 
should  assess  existing  personnel/facility  resources  and 
determine  future  requirements.  Also  the  program  manager 
measures  overhead  and  determine  the  efficiency  of  resource 
allocations  in  multiple  development  task  projects. 
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TABLE  2 

COST  DBI7BBS  USED  II  VARIOUS  COST  MODELS  [Bef.  6 


soc 

TRX* 

Njtnam 

RCA 

80EINC 

GRC 

GROUP 

factor 

IMS 

i*T7 

SLIM 

00 Ty  price  S  'EM 

1»77 

ifTS 

coco  MO 

SO  F  CO  ST 

OSN 

.ENSfN 

SIZE 

SOU  MCE  INSTRUCTIONS 

X 

X 

X 

X 

X 

X 

X 

X 

attributes 

object  instructions 

X 

X 

X 

NUMBER  09  ROUTINES 

X 

X 

NUMBER  Of  OATA  ITEMS 

NUMBER  QP  OUT  RUT  FORMATS 

X 

X 

X 

X 

X 

documentation 

X 

X 

X 

X 

NUMBER  Of  PERSONNEL 

X 

X 

X 

X 

X 

moonam 

TYPE 

X 

X 

X 

X 

X 

X 

X 

ATT  Ml  MJTIS 

COMPLEXITY 

X 

X 

X 

X 

X 

X 

X  1 

LANGUAGE 

X 

X 

X 

X 

X 

X 

MEUSE 

X 

X 

X 

X 

X 

X 

*  1 

REQUIRE 0  RELIABILITY 

DISPLAY  REQUIREMENTS 

X 

X 

X 

X 

X 

jj 

COMPUTER 

TIME  CONSTRAINT 

X 

X 

X 

!  * 

X 

X 

X 

X 

X 

X 

I  ATTRIBUTES 

j 

STORAGE  CONSTRAINT 

HARDWARE  CONRfGURRTION 
CONCURRENT  HARDWARE 

X 

X 

M 

1  X 

X 

X 

X 

X 

*  ! 

DEVELOPMENT 

X 

X 

X 

X 

X 

X 

>  ! 

INTERPACING  EQUIPMENT  SAX 

X 

X 

PE  L 

PERSONNEL  CAPAEILITY 

X 

X 

X 

X 

X 

X 

ATTRIBUTES 

PERSONNEL  CONTINUITY 

X 

X 

hardware  experience 

X 

X 

X 

X 

*  1 

X 

X 

X 

*  1 

APPLICATIONS  EXPERIENCE 

X 

X 

X 

X 

* , 

X 

X 

X 

x  1 

LANGUAGE  EXPERIENCE 

X 

X 

x  1 

X 

X 

X 

X 

PROJECT 

tools  ano  techniques 

X 

X 

X 

X 

X 

X 

V  i 

attributes 

customer  INTERPACE 

X 

X 

X 

X 

i 

REQUIREMENTS  DEFINITION 

X 

X 

X 

X 

X 

*  1 

REQUIREMENTS  VOLATILITY 

X 

X 

X 

X 

X 

X 

X 

X 

SCHEDULE 

X 

X 

X 

X 

SECURITY 

X 

X 

X 

i 

COMPUTER  ACCESS 

X 

X 

X 

X 

X 

X 

X 

X 

TRAVCL/REMOSTING/MUL  THITE 

X 

X 

X 

X 

X 

SUPPORT  software  maturity 

X 

X 

CALIBRATION 

factor 

X 

X 

X 

EFFORT 

EQUATION 

“*V)M  -CIDSII*  *  . 

1.0 

I  OPT 

O.SI 

f  0 

l  OS-  1  ? 

I  0 

'J 

SCHEOULE 

EQUATION 

i0  ■  e  iwm*  x  . 

0.35 

oj2  -  oja 

QJM 

0.333 

It  is  important  for  the  program  manager  to  develop  reli¬ 
able  estimates  by  performing  parallel  calculations  on 
multiple  models. 


IV.  SLIH 


The  SLIH  model  is  a  comprehensive  software  cost  esti¬ 
mating'  package  produced  by  Quantitative  Software  Management 
Inc.  SLIM  is  an  aid  for  effectively  managing  software 
development.  Using  engineering  technigues,  SLIM  provides 
cost,  time,  personnel,  and  machine  estimates  for  developing 
computer  software  systems.  SLIM  identifies  limiting 
constraints  that  affect  development  plans.  Confidence 
levels  and  risk  factors  are  calculated  to  provide  the 
manager  with  the  data  needed  to  make  decisions  on  cost, 
schedule,  effort,  quality,  manloading,  and  cash  flow.  The 
SLIM  ,  software  costing  and  management  system  does  these 
things  fief.  2]: 

1.  Determines  the  size  of  the  system  in  source  statements 

2.  Estimates  the  people,  cost  and  schedule  for  the  project 

3.  Projects  cashflow  over  the  life  cycle 

4.  Identifies  limiting  constraints  on  manpower  aDd 
schedu le 

5.  Obtains  risk  projections  for  cost  ana  schedule 

6.  Updates  estimates  from  the  real  data  once  development 
is  underway 

7.  Dynamically  adjusts  for  requirements  changes  to  give 
new  cost  and  schedule 

The  SLIM  model  is  claimed  to  Le  valid  for  any  system 
where  at  least  two  of  the  following  four  criteria  apply: 

1.  5000  lines  cf  code  or  greater 

2.  $100,000  or  more  in  development  costs 

3.  Pea*  manpower  cf  3  people  or  more 

4.  Development  time  of  6  months  or  longer 

Over  sixty  large  organizations  such  as  DOD,  I3M,  and  GIZ 
have  used  the  SLIM  package.  SLIM’s  accuracy  has  been  tested 
for  over  1300  systems  of  all  types  in  the  United  States  and 


"SLIM  is  the 


Europe.  International  Data  Corp.  comments, 
single  most  useful  management  tool  for  software  development 
that  I  am  aware  of  at  this  time"  [Bef.  2]. 

A.  SOFTWARE  EQ  RATIO! 

The  life-cycle  curve  can  be  mathematically  represented 
by  the  Rayleigh  eguation,  a  mathematical  form  from  the 
Keibull  family  of  reliability  functions.  Putnam  [Ref.  1] 
has  studied  the  manpower  versus  time  pattern  of  several 
hundred  medium  to  large  scale  software  development  projects 
of  different  classes.  These  projects  all  exhibit  a  similar 
life  cycle  pattern  of  behavior  -  a  rise  in  manpower,  a 
peaking  and  a  tailing  off.  The  Rayleigh  eguation  is: 

I  *  (K  /  t  2  )  t  exp  (  -  t*  /  2  t  *  ) 
d  d 

K  =  life-cycle  effort  in  man-years ( MY)  ,  man-months(Md) . 

t  =  development  time  in  years(Y)  ,or  months  (M) 
d 

• 

Y  =  manpower  in  man-years,  man-months,  or  just  plain 
countable  at  any  instant  in  time 

t  =  the  elapsed  time  in  years  or  months. 

Putnam  [Ref.  14]  points  out  why  the  Rayleigh  equation  is  a 
good  software  function: 

1.  It  is  a  management- oriented  function 

-  area  is  proportional  to  cost 

-  time  parameter(  t  )  proportional  to  schedule 

d 

-  curve  is  manpower  at  any  time  and  is  proportional 
to  spending  rate 

2.  Initial  slope  is  the  manpower  build-up  rate 

3.  Minimum  time  for  a  project  is  related  to  maximum 
manpower  acceleration  -  minimum  time  becomes 
predictable 

4.  code  production  rate  for  system  is  Ra  yleign- like 

5.  Error  rate  is  Rayleigh- like 
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v'  • 

1  .  *  k  r k' 


6.  Hayleigh  management  paraaeters  can  be  easily  turned 
into  a  linear  prograa  with  important  aanageaent 
constraint  (manpower,  cost,  schedule)  properly 
considered  to  yield  constrained  optimal  solutions. 
Figure  4.1  [Ben.  2]  shows  the  Rayleigh  function  as  a  manage¬ 
ment  tool. 


MANPOWER 


SLOPE  -  MANPOWER  3UILOUP  RATE  (K/t^2) 


Figure  4.1  Eayleigh  Function  as  Software  Management  Tcol. 

The  Rayleigh  eguation  is  linearized  by  talcing  loga¬ 
rithms, 

Ln(y/t)  *  Ln  <K  /  t  2)  +  (-1/2  t  *  )  t*  . 

d  d 

Upon  plotting  tnis  eguation  in  terms  cf  manpower  applied  to 
a  system  over  time  sguared,  a  straight  line  is  provided  in 
which  L n (  k  /  t^2  )  is  the  intercept  and  (  - 1  /  2  t^2  )  is 
the  slope.  Putnam  [Ref.  8]  performed  this  operation  for  one 
hundred  systems  and  found  that  the  argument  of  the  intercept 
(  K  /  t^2)  has  a  most  interesting  property.  Putnam 
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[  Bef .  1]  suggests  that  the  ratio  K  /  t  ^  2  represented  the 
difficulty,  D,  in  terms  of  the  programming  effort  and  the 
time  to  produce  it.  By  taking  the  gradient  of  D,  he  gets 

t  V  0 1  =  K  /  t3  =  Constant 
d 

This  difficulty  gradient  reflects  the  organizational  capa¬ 
bility  in  doing  that  type  of  work  for  which  the  constant  was 
derived.  The  difficulty  in  the  development  of  the  software 
varies  inversely  with  the  value  of  the  gradient,  i.e,  the 
most  difficult  projects  have  the  smallest  gradient.  From 
observation,  Putnam  [Ref.  2]  suggests  |V  D  |  is  guantized  at 
the  following  levels:  7.3  for  new  developments  with  inter¬ 

faces  to  other  programs;  14.7  for  a  new  stand-alone  develop¬ 
ment  project;  26.9  for  a  re-building  of  an  existing  program; 
55.0  for  a  composite  system  1;  and  89.0  for  a  composite 
system2  containing  much  existing  code.  These  values's 
uncertainty  is  about  15  percent  of  the  base  value.  When  the 
difficulty  is  plotted  against  productivity  rate,  PR6,  for  a 
number  of  systems,  Putnam  gets  the  relationship 


n 


C  =  productivity  constant 
n 

The  area  under  the  coding  rate,  S^,  curve7  is  the  total 
quantity  of  final  end  product  source  statements  that  will  be 


produced  by  time  t  [Ref.  5].  That  is,  source  statements  are 
produced  during  the  design  and  coding  subcycle  of  Rayieign 
curve.  Thus,  the  integral  of  the  manpower  rate  for  this 
subcycle  multiplied  by  the  productivity  gives  source  state¬ 
ments.  from  the  above  reasons,  Putnam  [Ref.  1]  develops  a 

6total  end  product  code  /  total  effort  to  produce  code 
Productivity  rate  »  manpower  =  PR  *  Y 


mathematical  relationship,  the  SLIM  software  equation,  which 
is  an  powerful  tool  for  planning  and  evaluating  the  develop¬ 
ment  effort  life  cycle.  The  software  equation  is: 


S*  •  /  Ss  •  dt  ■  /  FW  .  y,  .  dt  ■  RT 


S 

s 

c 

k 


K  * 


=  number  of  delivered  source  instructions 
=  state  of  technology  constant 


t  is  equivalent  to  Bayleigh  equation  parameters 


Putnam  [Sef.  15]  observed  that  the  time  at  which  the 
Rayleigh  curve  reaches  its  maximum  value,  t^  ,  corresponds 
to  the  time  cf  system  testing  and  product  release  for  many 
software  products.  That  is,  normally  peak  manpower,  Y  max, 
exists  as  a  function  of  development  time(t^). 


* 

Y 

max 


The  area  under  the  Rayleigh  curve  interval  represents  the 
total  effort  expended  in  that  interval.  Approximately  forty 
percent  of  the  area  under  the  Rayleigh  curve  is  to  the  left 
of  t^  and  sixty  percent  is  to  the  right.  3y  rearranging  the 
software  equation  and  applying  a  factor  of  .4  to  reflect 
that  the  development  effort,  E,  is  approximately  the  first 
forty  percent  of  the  life  cycle  curve. 


=  .  4 


4 


E  (MM,  MY) 


.  4K 


/  t 


B?  applying  tie  burdened  labor  rate  (  average  dollar 
cost  per  man  year  or  man  month  of  effort),  tte  equation 
changes  to  cost 


Development  cost  =  (  $  /  MY)  .4 


B.  UHCBBTAINTY  AHALYSIS 

Almost  every  factor  entering  into  an  estimate  of  effort, 
and  schedule  is  subject  to  seme  degree  of  uncertainty.  The 
manager  needs  to  portray  the  effects  of  the  uncertainty 
associated  with  each  of  these  factors.  To  get  a  reasonable 
estimate  of  uncertainty  in  life-cycle  effort  and  development 
time,  Monte  Carlo  simulation  is  used.  Given  , 

|  VD  i  ,  and^yiVD),  Putnam  [Bef.  2]  obtained  statistics  on 
variablity  of  the  effort  and  develop  time  from  several  thou¬ 
sand  samples.  From  the  SLIM  software' equation  and  the  diffi¬ 
culty  gradient  equation,  we  make  the  equation  as  follows: 


t 


d 


1  /  7 


K  =  |  V  D  |  t  3 

a 

Also  the  standard  deviation  {  6 1  ^  ,  <f  K  )  obtained  from  a 

Monte  Carlo  simulation  will  be  used  to  make  a  risk  analysis 
profile.  An  APL  program  for  this  simulation  analysis  of 
estimating  development  time,  effort,  and  the  major  milestone 
time  is  shown  in  Figure  4.2. 
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B3 


'  N  COMPUTE  INPUT; XX ; YY ; TD ; K ; BAR ;KK 
TO  COMPUTE  DEVELOPMENT  EXPECTED  TIME  AND  EFFORT. 
TO  COMPUTE  STANDARD  DEVIATION  OF  TIME  AND  EFFORT, 
TO  GENERATE  THE  MAJOR  MILESTONE  OF  THE  PROJECT. 


SIMULATION  RUNNING  NUMBER. 
TECHNOLOGY  CONSTANT. 
SOFTWARE  SIZE  MEAN. 

SOFTWARE  SIZE  STANDARD  DEV. 
DIFFICULTY  GRADIENT  MEAN. 


IMPUTM 

inputtz; 

INPUTT3 
INPUTT4 

INPUTt5j;  DIFFICULTY  GRADIENT  STANDARD  DEV. 

TO  CALL  RANDOM  NUMBER  GENERTORS  FOR 

SOFTWARE  SIZE  AND  DIFFICULTY  GRADIENT. 

XX*-N  GAUSS  INPUTT21 ,  INPUTT31 
YY <-N  GAUSS  INPUTC4j,  INPUTC5] 

TD**(  (  (XXrlNPUTM  3>#3>+YY>*<f  ^7) 

T<-3T(BARX  (+/TD)-rN)x12) 

'DEVELOPMENT  TIME  (MONTH)  =  ‘  ,T 
SDTr-3T(  (  (♦/(  ( (TDxi  2) -BAR)  #2)  )^N-t  )*0.5) 
'DEVELOPMENT  TIME  S.D  =  ',SDT 
K«-YY*(TD*3) 

DM«-3T  (  (0.4*  (!<!<«- <+/K  )+N)  )  xl  2) 

‘DEVELOPMENT  EFFORT  (MM)  =  '  DM 
SDM«-3T (  (  (>/(  (  <!<-KK  )  xl  2x0. 4) *2)  >r-N-1  >*0.5) 
’DEVELOPMENT  EFFORT  S.D  =  1 , SDM 
>  TO  GENERATE  THE  MAJOR  MILESTONES  OF  THE  PROJECT 


C .  D .  R 
F.C.C 
1  S.I.T 
U.O.S.T 
1  I.O.C 
F.G.C 


3T ( BAR x 0.43) 
3T  (  BARxO .  57 ) 
,  3T(BARX0.67) 
,  3T ( BARxO » 8 ) 

,  3T ( BARxO . 93) 
3T ( BAR ) 


v  Z  <-N  GAUSS  PAR 

ft  SAMPLE  RANDOM  NUMBER  GENERATORS 
ft  N;  SAMPLE  SIZE 

a 


[3]  ft  PART  1 0 ;  MEAN  ,  PART21,  STANDARD  DEV. 

L4]  Z ‘■PAR Cl  J+PARC23x"6+1E“6x  12++/?(N,  12)p100000i 


Pigure  4.2  4 PL  Program  for  Development  Time  and  Effort. 

Linear  programming  is  used  to  obtain  the  two  most  impor¬ 
tant  answers  in  software  development  pro jec ts-miniaum  time 
and  minimum  cost.  These  "best  possible"  solutions  also  bound 
the  ranqe  of  reasonable  solutions  -  all  feasible  solutions 
lie  in  between  these  extremes  and  are  explicitly  identified. 
The  linear  programming  (L? )  approach  has  another  great 
advantage.  It  produces  constrained  optimal  solutions.  The 
SLIM  model  has  introduced  the  most  important  software 
management  constraints  --  maximum  cost,  required  delivery 
time,  and  staffing  capability  —  into  the  problem.  This 
gives  the  program  manager  real  control  in  his  own  domain  of 
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resource  allocation  and  control  [Ref.  2].  The  equations  for 
the  LP  formulation  are  as  follows: 


1/3  V3 

S  =  C  K  t 

s  k  d 


software  equation 


K  /  t  <  7e"  Y 

d  =  max 


maximum  peak,  manpower 


k  /  t  >  yr  r 

a  = 


min 


minimum  peak  manpower 


K  /  t  <  |D 
d 


maximum  difficulty 


K  /  t  <  |  V  D 

d 


maximum  difficulty  gradient 


t  <  contract  delivery  time 
d  = 


($  /  MY)  (  .4  K  )  <  total  budgeted  amount  for  development 


These  can  be  solved  with  graphic  or  simplex  methods. 
Figure  4.3  shows  LP  graphical  feasibility  solution  using 
LOG-LOG  tLa  ns  forma  tion  plot.  [Ref.  2] 

C.  AVAILABLE  OPTIONS 

The  SLIM  function  routine  is  composed  of  three  options: 
top-level,  what-ir  option,  and  implementation  option. 
Figure  4.4  shews  the  SLIM  methodology.  [Ref.  4] 
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1.  Top-level  Option 

The  top-level  functions  in  SLIM  include:  Calibrate 

input,  project  input,  and  project  estimate.  The  process  by 
which  a  model  is  tailored  to  a  particular  class  of  systems 
with  the  intent  of  making  it  a  better  predictor  is  called 
calibration.  It  is  important  for  the  program  manager  to  try 
to  tailcr  his  model  from  his  past  data. 

a.  Calibrate  Input 

Allows  user  to  calibrate  historic  projects  for 
productivity  and  manpower  buildup  indexes. 

b.  Project  Input 

Prompts  user  for  all  project  estimate  informa¬ 
tion  and  builds  or  modifies  project  date  files. 

c.  Project  Estimate 

Provides  all  cost,  schedule,  manpower,  quality 
and  risk  estimates  for  a  software  project.  Once  a  minimum 
time  solution  has  been  established  the  management  what-if 
options  can  be  used  to  impose  project  constraints.  fchen  an 
acceptable  solution  is  chosen  the  implementation  options  can 
generate  a  consistent  set  cf  work  plans. 

2.  F hat- if  Option 

It  is  important  for  the  program  manager  to  try 
sensitivity  analysis.  Unless  it  is  essential  that  the  soft¬ 
ware  be  built  in  the  minimum  time,  the  estimator  should 
consider  alternative  solutions  that  take  longer  but  cost 
less.  The  what-if  functions  provide  the  anility  to  explore 
additional  build  strategies  that  take  longer  and  could 
better  suit  the  estimator's  needs.  The  management  what-if 


a.  Design  to  Schedule 

SUM  will  automatically  determine  the  minimum 
time  schedule  for  which  development  of  the  system  is 
feasible.  This  function  may  be  used  to  set  an  alternative 
schedule  for  development.  A  new  corresponding  cost,  effort 
and  peak  manpower  will  be  provided. 

b.  Design  to  Cost 

This  function  is  used  to  allow  the  user  to  set  a 
new  cost  for  development.  A  new  time  schedule,  level  of 
effort  and  peak  manpower  will  be  generated. 

c.  Design  to  Effort 

This  function  is  used  to  allow  the  user  to  set  a 
new  level  or  effort  for  development.  A  new  time  schedule, 
cost  and  peak  manpower  will  be  generated. 

d.  Design  to  Risk 

This  function  uses  the  trade-off  law  together 
with  a  user  specified  level  of  risk  of  not  exceeding  a 
required  delivery  date  to  generate  an  expected  development 
time,  level  of  effort,  cost  and  peak  manpower. 

e.  Design  to  Reliability 

This  function  permits  the  user  to  input  a  speci¬ 
fied  Mean  Time  To  Fail ure ( flTTF)  .  It  then  determines  the 
appropriate  development  time,  effort,  cost  and  peak  manpower 
to  meet  that  MTTF  together  with  the  estimated  number  of 
errors  and  error  rates. 

f.  Linear  Program 

This  function  uses  the  technique  of  linear 
programming  to  determine  the  minimum  effort  (and  cost)  or 
the  minimum  time  in  which  a  system  can  be  built.  The  results 


ace  based  oc  the  actual  manpower,  cost,  and  schedule 
constraints  cf  the  user,  combined  with  the  system 
constraints  described  earlier  to  yield  a  constrained  optimal 
solution. 


g.  Best  Bid 

This  function  picks  the  best  time-effort  combi¬ 
nation  by  maximizing  the  joint  probability  that  the  develop¬ 
ment  time  is  greater  or  egual  to  a  user-  specified  end  date 
and  the  cost  is  less  or  egual  to  a  user-  specified  cost. 

h.  Temporary  Change 

This  function  lets  the  user  temporarily  chance 
up  to  nine  parameters-  title,  start  date,  size,  standard 
deviation  on  size,  labor  rate,  uncertainty  on  labor  rate, 
inflation  rate,  productivity  index  and  manpower  ouiliup 
index. 

3.  Implemention  option 

Once  the  estimator  has  found  a  solution  that  best 
suits  the  estimator's  requirement,  the  estimator  wili  need  a 
set  of  detailed  plans  to  implement  the  solution.  By  periodi¬ 
cally  comparing  progress  of  the  development  with  the  plan, 
the  estimator  has  tne  means  to  control  all  phases  of  the 
software  development  from  the  oeginning  of  the  feasibility 
study  through  completion  of  operation  and  maintenance.  The 
implementation  options  include: 

a.  Manloading 

This  function  provides  projections  of  the  mean 
number  of  people  (and  standard  deviation)  that  will  be 
applied  to  the  project  throughout  development.  These 
projections  are  based  on  an  optimal  application  of  resources 
over  time. 
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b.  Cashflow 


This  function  provides  projections  of  the 

expected  cashflow  on  a  m onth-to-month  basis  throughout 
development  of  the  system. 

c.  life-Cycle 

This  function  provides  projections  of  the 

expected  manpower  and  cashflow  throughout  the  life-cycle  of 
the  system.  #  Projections  are  provided  on  a  monthly,  quar¬ 
terly,  or  yearly  basis. 

d.  Risk  Analysis 

This  function  determines  the  probability  of 

developing  a  system  within  a  specified  time  or  for  a  speci¬ 

fied  cost,  it  is  very  useful  for  strategic  planning  purposes 
by  providing  the  associated  with  various  time  and  cost 
decisio  ns. 

e.  Hcrk  Breakdown 

This  function  shows  a  breakout  of  effort  devoted 
to  specific  skill  categories  as  a  function  of  the  develop¬ 
ment  schedule. 

f.  Effort  Between  Milestones 

This  function  shows  a  breakout  of  effort 
devoted  to  principal  activities  as  a  function  of  the  devel¬ 
opment  schedule. 

g.  Milestones 

Based  on  a  predetermined  total  development  time, 
this  function  provides  a  realistic  schedule  for  the  major 
milestones  of  the  project. 
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h.  Code 

This  function  provides  a  rate  of  code  produc¬ 
tion  and  cumulative  code  production  for  valid  end  product 
cost.  Top  down  structured  programming  is  assumed. 

i.  Gantt  Chart 

This  function  provides  a  Gantt  Chart  of  activity 
phases  and  their  respective  milestones.  It  will  reflect 
whether  the  design  and  coding  is  done  in  a  top-down  struc¬ 
tured  method  or  with  a  formal  critical  design  review 
followed  by  a  coding  phase. 

j.  Front-End  Estimates 

This  function  provides  low,  average,  ar.d  hign 
estimates  of  the  time  and  effort  reguired  for  the  feasi¬ 
bility  study  and  design  phase. 

k.  CEO  Osage 

This  function  provides  a  table  of  expected 
machine  usage  over  the  life  cycle  of  the  system,  along  wita 
an  estimate  of  total  machine  hours  reguired  for  development. 

l.  Reliability 

This  function  gives  projections  of  error  rate, 
cumulative  errors  created,  found  and  fixed,  and  Mean  Time  To 
Failure  month  by  month  until  a  reliability  of  .  995  is 
achieved. 

m.  Documentation 

Based  on  tne  total  system  size  and  data  from 
hundreds  of  similar  software  systems,  a  range  of  expected 
pages  of  documentation  is  given. 
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n.  So««ary  of  Development  Costs 

This  function  provides  a  summary  of  the  major 
development  costs  for  the  system.  These  costs  include  labor 
costs  and  CPU  costs  over  time  and  the  total  documentation 
cost. 

o.  Benefit  Analysis 

This  function  computes  the  benefit  of  the  system 
required  to  amortize  the  cost  of  development  and  mainte¬ 
nance.  It  is  based  on  the  anticipated  economic  life  of  the 
system  as  well  as  the  average  rate  of  return  for  the 
organization. 

The  SLIM  model  furnishes  an  effective  means  to  estimate 
and  control  the  cost,  schedule  and  manpower  requirements  of 
building  and  maintaining  medium  size  to  very  large  software 
systems.  The  program  manager  can  tailor  his  estimates  to 
meet  all  realistic  constraints  imposed  on  the  development. 
After  an  intensive  evaluation  of  the  SLI3  approach,  the 
Department  of  Defense  adopted  the  methodology  as  the  stan¬ 
dard  macro  estimating  technique  to  be  used  on  major  software 
systems  in  all  services  and  defense  agencies. 


V.  PROCEDURE  AMD  DATA  BASE 

Most  common  methods  of  software  costing  start  with  esti¬ 
mation  of  the  number  of  instructions.  Boehm  [Ref.  6]  said 
the  biggest  difficulty  in  using  today's  algorithms  in  soft¬ 
ware  cost  models  is  the  problem  of  providing  sound  sizing 
estimates. 

Putnam  [Ref.  1]  suggests  that  in  the  systems  definition 
phase,  we  dc  estimate  a  rough  idea  of  the  system  size 
(source  statements)  and  establish  bounds  on  manpower  effort 
and  development  years.  In  the  requirement  and  specification 
phase,  the  cumber  or  files,  reports,  and  application 
programs  are  good  estimators  of  the  size  of  the  system  and 
hence  the  time  and  effort  required. 

This  paper  is  an  investigation  of  ways  in  which  we  might 
be  able  to  estimate  the  size  of  a  new  project,  cased  on 
Putnam's  existing  data  base  of  close  to  one  thousand 
systems.  Breakouts  have  been  made  of  that  data  base  by 
application  type  and  the  average  size  and  the  standard  devi¬ 
ation  of  each  of  those  application  types  has  been  calcu¬ 
lated.  The  estimator  can  be  approached  in  a  Bayesian  sense, 
such  that  if  it  is  a  scientific  system,  then  it  would  fail 
somewhere  in  the  range  for  a  scientific  system.  This  would 
be  the  Bayesian  prior.  Then  this  category  is  presented 
graphically,  and  the  person  asked  whether  it  tends  to  be 
toward  the  low  end  of  this  category,  toward  the  high  end  of 
this  category,  or  low-middle  or  high-middle.  By  doing  some 
statistical  analysis,  it  is  possible  to  come  up  with  a 
weighted  expected  value  and  a  new  estimate  of  a  standard 
deviation  gust  by  using  the  person's  notional  choice  and  the 
PERT-sizina  formula.  This  would  be  a  Bayesian  likelihood 
estimate;  it  could  be  combined  together  with  the  prior  using 
Bayes'  theorem.  The  usefulness  of  the  Bayesian  approach  to 
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statistical  inference  rests  upon  the  usefulness  of  incorpo¬ 
rating  personal,  subjective  beliefs  directly  into  the 
analysis. 

From  Bayesian  inference  and  decision,  it  may  be  seen 
that  the  posterior  probabilities  are  derived  directly  from 
prior  probabilities  and  the  likelihoods.  It  should  again  be 
recalled  that  the  mean  and  standard  deviation  of  a  normally 
distributed  random  variable  completely  specify  its  prob¬ 
ability  function.  Further,  it  is  easily  provided  by  means 
of  the  calculus  that  if  the  prior  probability  and  the  like¬ 
lihood  are  both  normally  distributed,  the  posterior  prob¬ 
abilities  must  be  normally  distributed.  The  reciprocal  of 
the  posterior  variance  (  tf2  )  is  equal  to  the  sum  of  tne 
reciprocal  of  the  prior  variance  (  g2  )  and  the  reciprocal 
of  the  likelihood  variance  (  4 2  ) ,  reflecting  the  fact  that 
the  two  sources  of  information  are  pooled  together.  The 
posterior  mean  (E2  )  i-s  a  weighted  average  of  the  prior  mean 
(E 0  )  and  the  sample  mean  (E  j  ),  the  weights  being  the 
reciprocals  of  the  respective  variance  [Pefs.  16,17].  The 
equations  are  as  follows: 


1  1  1 


E 

2 


These  posterior  means  and  standard  deviations  will  be  used 

1 

as  SLIM  input  parameters. 


1.  QSH  DATA  EASE 


QSH  (Quantitative  Software  Management),  Inc.  is  a  company 
formed  to  help  estimators  solve  critical  cost  and  schedule 
control  problems  in  business  and  government.  The  QSM  data 
base  is  composed  of  one  thousand  systems  from  DOD,  RADC  (Some 
Air  Development  Center),  CJS  Army  Computer  Systems  Command, 
and  various  companies.  Appendix  G  shows  a  sample  for  data 
format.  The  QSM  data  base  is  composed  of  ten  types  as  shown 
in  Table  3. 


TABLE  3 

- ] 

QSH  DATA  BASE  BY  APPLICATION  TYPE 

Application  Type 

No.  System 

A  vg 

system  size! 

1 

Micro  cede/  Firm  ware  data  case 

11 

17435 

2 

Real-time  data  base 

125 

56870 

3 

Avionic  data  base 

26 

80  186 

4 

system  Software  data  base 

75 

75035 

5 

Command  £  Control  data  base 

61 

bl  452 

6 

Telecom  data  base 

32 

42179 

7 

Scientific  data  base 

82 

91265 

8 

Process  Control  data  base 

11 

52780 

9 

Business  data  base 

547 

71693 

1C 

Unknown  application 

1 

140300 

Mixed  Application  data  base 

971 

69549 

_ i 

Table  4  shows  that  QSfl  data  base  divided  by  size  range. 

B.  PROCEDURE 

This  idea  is  that  by  partitioning  the  data  base 
according  to  statistical  sub-groups,  we  estimate  new  project 
size  using  Bayesian  inference.  It  may  be  possible  to  come 
close  enough  to  the  true  value  to  give  meaningful  software 
estimates  in  early  feasibility  study  phases  of  a  major 
project.  The  procedure  consists  of  five  steps. 
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TABLE  4 

QSH  DATA  BASE  BY  SIZE  EAHGE 


1.  Deter  nine  Application  Type 


The  different  system  types  have  unique  properties 
which  have  to  be  considered  so  that  parameters  can  be  tuned 
to  these  properties.  It  is  important  to  know  what  kind  of 
software  application  type  will  be  made.  Using  each  applica¬ 
tion  type's  mean  and  standard  deviation,  we  get  statistical 
results  from  running  the  SLIM  model.  Appendix  A  shows  the 
test  case.  In  the  test  case,  it  is  assumed  that  time  is 
estimated  within  2  percent  and  effort  within  9  percent. 
Appendix  E  shows  the  extreme  case.  In  the  extreme  case, 
time  is  estimated  within  30  percent  and  effort  within  80 
percent. 


2.  Select  Size  Category  and  its  0 uantile 

Project  size  is  a  major  factor  that  determines  the 
level  of  management  control  and  the  types  of  tools  and  tech¬ 
niques  required  on  a  software  project.  Initially  the  program 
manaqer  determines  the  size  category  from  Table  4  and,  based 
on  the  possible  spread  range,  he  considers  the  overlap  on 
both  sides  of  the  the  category  range.  From  application  type 
and  size  range,  the  program  manager  can  choose  the  proper 
mean  and  standard  deviation  cf  software  size  from  Appendix 


For 


C.  It  will  be  used  for  Bayesian  prior  estimates, 
example,  let  us  select  the  category  size  of  large.  For  this 
selection  range  of  75K-2Q0K,  the  overlap  range  is  graphi¬ 
cally  represented  in  Figure  5.1. 


Figure  5.1  Hhere  it  Falls  in  the  Range  (Large). 

Now  select  a  size  range  from  Low,  Middle  Low,  Middle 
High,  High.  Assuming  that  the  size  is  approximately 
normally  distributed,  we  can  use  these  as  Bayesian  likeli¬ 
hood  estimates.  These  size  ranges  are  also  shown  in  Figure 
5.1.  The  program  manager  believes  it  falls  in  the  second 
quantile  which  we  call  "Mid  Low".  Using  weighted  means  and 
the  PERT-sizing  formula,  the  project  manager  can  get  the 
mean  and  standard  deviation  of  software  size. 


S  =  (5  0  +  4  (125)  +250)  /  6  =  133-  3  (K) 

<Ts  =  (  250  -  50  )  /  6  =  33.  (K) 


The  other  size  categories  and  their  respective  quantiles  are 
represented  in  Appendix  D. 


3.  Coa p u te  Mew  Mean  and  Standard  Deviation 

To  get  posterior  mean  and  standard  deviation  as 
input  parameters  for  SLIM,  we  use  the  Bayesian  approach.  We 
combine  prior  estimate  from  application's  type  and  size  and 
likelihood  estimate  from  the  program  manager's  subjective 
belief. 

4.  Run  S1IM 

The  project  estimates  provide  all  cost,  schedule, 
manpower,  quality,  and  risk  estimates  for  a  software 
project.  This  output  is  used  to  determine  the  minimum  time 
development  strategy  and  its  associated  uncertainty.  Once  a 
minimum  .time  solution  is  established  the  program  manager 
should  use  the  management  what-if  options  to  impose  project 
constraints.  When  an  acceptable  solution  is  obtained,  use 
the  implementation  reports  and  graphs  to  generate  a  set  of 
work  plans. 

5 •  Analysis 

To  analyze  the  sensitivity  of  our  solution  to  varia¬ 
tions  in  the  size,  we  use  the  temporary  change  routine.  The 
report  for  temporary  changes  will  contain  a  summary  of  the 
changes  and  a  new  minimum  time  solution  based  upon  tne 
changes.  Results  of  the  minimum  time  solution  are  output  in 
three  tables.  The  first  table,  the  minimum  time  solution, 
gives  a  consistent  set  of  management  metrics  (mean  and  stan¬ 
dard  deviation)  for  building  the  system  in  the  shortest 
possible  time.  The  second  table,  a  sensitivity  profile, 
shows  hew  the  management  metrics  change  as  a  result  of  one 
and  three  standard  deviation  changes  in  the  system  size 
(mean).  The  third  table,  a  consistency  cneck,  compares  the 
estimator's  solution  with  historical  data  for  systems  of 
comparable  size  in  the  QSM  data  base. 
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All  the  variables  of  the  software  equation  are 
subject  to  some  degree  of  uncertainty  and  the  program 
manager  must  have  a  means  of  taking  this  into  account  in  an 
effort  development  risk  profile.  Putnam  [Ref.  1]  suggests 
risk  analysis  is  probably  the  most  important  aspect  of  any 
software  system  analysis.  In  an  uncertain  process,  risk 
analysis  measures  the  uncertainty  to  let  us  develop  proper 
strategies  to  minimize  the  risk. 

C.  EXAHPLE 

Let  us  examine  a  scientific  type  example  in  which  a  new 
stand-alone  development  project  will  be  made.  Initially  the 
program  manager  relieves  that  the  project  size  category  will 
he  large.  3y  observing  the  graphical  representation  of  tha 
range,  the  program  manager  subjectively  estimates  that  toe 
project  falls  into  "Mid  Low’1  range.  For  a  scientific 
"Large"  project,  we  can  derive  prior  estimates  for  the  mean 
and  standard  deviation  of  117389  and  34508  respectively  from 
Appendix  C.  Also  we  calculate  likelihood  estimates  of  mean 
and  standard  deviation  of  133300  and  33000  respectively  from 
Appendix  D,  where  it  fails  in  the  "Mid  Low"  range.  From 
Bayesian  equations,  we  can  get  posterior  estimates,  as 
follows . 


1  _  _1__  1  _  1 

(T  2  2  ~  34 5088  330002  "  238502 


tr 

"2 


238502  238502 

- -  1  17389  ♦  -  133300 

345082  330002 


1 25700 
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These  estimates  vill  be  used  as  SLIM  input  parameters.  He 
assume  that  this  project  uses  average  manpower  and  produc¬ 
tivity  index.  Prom  running  the  SLIM  model,  we  get  the 
minimum  time  solution.  Knowing  the  minimum  development  time 
and  standard  deviation  give  the  program  manager  a  framework 
from  which  to  plan  and  control  the  software  development 
process.  From  Table  5,  for  the  minimum  time  solution,  the 
program  manager  should  consider  the  estimate  having  a  50 
percent  chance  of  being  realized  upon  completion  of  the 
system.  When  this  expected  value  is  added  to  its  standard 
deviation,  it  gives  a  new  value  that  has  an  34  percent 
chance  of  being  realized.  Also  the  perceot  of  expected  value 
of  the  standard  deviation  is  a  major  factor.  For  this 
example  it  is  as  follows: 

(ft  /  t  =  2.  1  /  23.4  =  .089 
d  d 

tfS  /  E  =  139  /  516.5  =  .269 


This  shows  that  development  time  is  estimated  within  9 
percent  and  effort  within  27  percent  in  one  standard  devia¬ 
tion.  The  ether  range  results  are  shown  in  Appendix  2. 
Appendix  F  shows  it  for  business  applications. 

Table  6  shows  the  corresponding  expected  values  for 


time,  effort  and  cost  by  increasing  one  and  three  standard 
deviation  of  system  size.  Also  it  shows  that  a  99  percent 
confidence  interval  of  development  time  is  between  16.2 
month  and  28.2  month. 

Table  7  shows  that  if  the  values  shown  ace  within  plus 
or  minus  45  percent  of  the  mean  for  systems  of  comparable 
size  in  the  data  base,  the  table  labels  them  as  "in  normal 
range”.  Otherwise  the  values  will  be  reported  as  either 
greater  than  or  less  than  the  normal  range. 


TABLE  5 

HIHIBUB  TIHE  S0L03ICN 


TITLE:  Thpgis  Example 


DATE I  20-SEP-199S 
TIME  I  11:27:46 


MANAGEMENT  METRIC 


SYSTEM  SIZE  (STATEMENTS) 

MINIMUM  DEVELOPMENT  TIME  (MONTHS) 

DEVELOPMENT  EFFORT  (MANMONTHS) 

DEVELOPMENT  COST*  (x  lOlKi  *) 

(UN INFLATED) 

(INFLATED) 

PEAK  MANPOWER  (PEOPLE) 


EXPECTED  VALUE 
(SOX  PROBABILITY) 


TABLE  6 

SENSITIVITY  PEOPILE 


-3  STD  DEV 
-1  STD  DEV 
EXPECTED 
I  +1  STD  DEV 
I  *3  STD  DEV 


SOURCE  STMTS 

34150. 

101850. 

125700. 

149550. 

197250. 


MONTHS 


MANMONTHS 


UN INFLATED 
COST  (X  1000) 

675. 

1607. 

2178. 

2635. 

3762. 


Figure  5.2  shows  the  major  milestone  time  for  the 
current  solution  as  a  statistical  expected  value,  i.e.  ,  the 
value  that  statistically  has  a  50  percent  probability  of  not 
being  exceeded  upon  completion  of  the  main  program. 

Table  8  sbows  the  probability  ranges  for  effort,  cost, 
and  time  from  1  percent  to  99  percent  — a  broad  enough  band 
to  cover  all  realistic  possibilities. 


TABLE  7 

i 

COBS 1ST £ NCI  TABLE 

MANAGEMENT  METRIC 

VALUE 

ASSESSMENT 

1 

TIME  (MONTHS) 

23.4 

IN 

NORMAL 

RANGE 

EFFORT  (MANMONTHS) 

316 

IN 

NORMAL 

RANGE 

AVERAGE  STAFFING  (PEOPLE) 

22 

IN 

NORMAL 

RANGE 

PRODUCTIVITY  (LINES/MM) 

243 

IN 

NORMAL 

RANGE 

,FOC 

IOC 


Figure  5.2  Bisk  Profile  (tine). 

From  the  tables  and  grapn,  the  program  manager  deter¬ 
mines  the  probability  that  other  times,  effort,  and  costs 
will  not  be  exceeded.  Development  time  and  milestones  are 
the  most  sensitive  elements  in  the  process.  Milestones  scale 
linearly,  meaning  that  if  the  project  manager  is  late  on  an 
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TIB IS  8 

PROBABILITY  PROFILE 


PROBABILITY 


MANMONTHS 


UN INFLATED 
COST  (X  S  lOOOl 


TIME  (MONTHS) 


early  milestone,  the  project  manager  will  very  likely  be 
late  on  succeeding  milestones.  It  is  important  for  the 
program  manager  to  remember  Brooks'  law:  Adding  manpower  to 
a  late  project  makes  it  later. 


VI.  CCHCLOSIOH  AHJ  B ECO MB EH DA TIP NS 


In  order  for  the  program  manager  and  his  support  team 
to  evaluate  a  software  cost  proposal,  they  must  have  a 
detailed  understanding  of  the  process  that  developed  the 
cost  estimate  and  should  have  some  traceanility  to  the  vari¬ 
ances  or  sensitivity  of  the  estimating  components.  It  is 
important  for  the  program  manager  to  recognize  the 
similarities/differences  between  the  defense  system  life 
cycle  and  the  other  commercial  development  life  cycle.  The 
program  manager  should  compare  various  cost  models  for 
alternative  estimates. 

The  life-cycle  curve  can  be  mathematically  represented 
by  the  Hayleigh  equation,  which  is  a  good  management  tool. 
For  planning  and  evaluating  the  development  effort  life 
cycle,  the  SLIM  model  is  a  very  powerful  tool. 

It  is  hard  to  estimate  software  size  in  the  early  phase 
of  system  development.  But  the  program  manager  can  estimate 
the  new  project  size  using  Bayesian  inference.  To  get  a 
Bayesian  estimate  of  software  size,  the  program  manager 
combines  a  prior  estimate  from  application's  type  ar.d 
category  size  with  a  likelihood  estimate  from  the  program 
manager's  subjective  belief.  When  combined  with  the  capa¬ 
bilities  of  the  SLIM  model,  the  development  time  is  esti¬ 
mated  within  15  percent  and  effort  within  30  percent  in  one 
standard  deviation. 

This  method  could  be  a  fruitful  way  to  get  at  tne  early 
estimating  prcnlem  in  a  gross  way,  yet  good  enough  to  get  in 
the  "ball  park"  of  what  people  need  at  that  phase  of  the 
pro  ject . 

Future  research  should  focus  on  the  relationship  between 
cost  attribute  factors  and  system  application  types. 


1PPEBDIX  A 


DISTBIBOTIOH  BY 

APPLICATION 

TYPE (BEST 

CASE) 

Application  Type 

Development  Time 

Effort 

Mean.  Std.  Dev 

Mean. 

Std. Dev 

1  Micro  code/Firm  ware 

10.00 

.  21 

16.0 

1.3 

2  Beal -time 

16.59 

.38 

174.0 

15.5 

3  Avionic 

19.20 

.  44 

282.9 

25.4 

4  system  Software 

18.69 

.  41 

257.0 

22.3 

5  Command  &  Control 

17.20 

.38 

192.7 

1  6.7 

6  Telecom 

14.61 

.30 

108.1 

8.3 

7  Scientific 

20.31 

.45 

334.3 

2  8.8 

8  Process  Control 

16.06 

.37 

156.  1 

1  4.3 

9  Business 

1  8.29 

.  40 

243.8 

20.5 

Mixed  Application 

18.05 

.  38 

233.5 

19-2 
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APPENDIX  B 

DISTRIBUTION  BI  APPLICATION  TYPE  (EXTREME  CASE) 


Application  Type 

Development  Time 

Effort 

Mean. 

Std.  Dev 

Mean. 

Std . Dev 

1  Micro  code/Firm  ware 

10.43 

3.  64 

24.8 

20.2 

2  Real-time 

21.37 

7.  10 

498.4 

420.8 

3  Avionic 

22.04 

7.  15 

553.7 

457.6 

4  system  Software 

21.64 

6.  85 

515.  1 

41  1.9 

5  Command  S  Control 

19.65 

6.  70 

400.6 

35  1.0 

6  Telecom 

16.33 

5.  49 

202.5 

173.5 

7  Scientific 

25.80 

10.  12 

975.8 

912.  b 

8  Process  Control 

18.17 

5.  25 

276.9 

206.4 

9  Business 

21.73 

7.  15 

525. 9 

427.  1 

Mired  Application 

20.93 

7.  36 

477.6 

417.7 

APPENDIX  C 

DISTRIBUTION  BY  APPLICATION  TYPE  AND  SIZE  BIN 
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APPENDIX  E 

SCIENTIFIC  DATA  BASE  EXPECTED  SIZE,  TIME,  AND  EFFOBT 
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APPENDIX  S 
QSB  SAMPLE  DATA 


Run  Date:  06-25-1985 
Run  Time:  11:00:59 


PROJECT  DETAIL  REPORT 
Project:  GROSS  MARGIN  ANLYS 


Page: 


Data:  05/21/85 
Organization: 


Project  name  :  GROSS  MARGIN  ANLYS 
System  number:  964 


SIZING  INFORMATION 

Total  Source  Statements: 
Name  of  Language 


23703 


Type 


%  of  Total  Size 


COBOL 

NATURAL 

JCL 


High  Level 
Non-Procedural 
High  Level 


22  % 
71  % 
7  % 

___  % 
% 


%  of  Total  Source  Statements 
Brand  New  (ss) :  100  % 

Modified  (ss) :  _  % 

Unmodified  (ss) :  _  % 


TIME -EFFORT -STAFFING 


Feasibility  Study: 

mos 

.5  mm 

Functional  Design: 

4  mos 

3.5  mm 

1.5  Pk  Mpwr 

Main  Software  Build: 

3  mos 

10  mm 

7  Pk  Mpwr 

Operations  +  Maint . : 

3  mos 

2.5  mm 

Overlap  (ncs 
Cose 


FOC  Date:  01/35 


OVERRUN/SLIPPAGE  (MAIN  SOFTWARE  BUILD) 
Time  Slippage:  _  mos 


Cost  Overrun: 


(mm) 


QUALITY  (MAIN  SOFTWARE  BUILD) 
Errors  (SIT-FOC) : 

Errors  (1st  mo  after  FOC): 


MTTF  (1st  mo  oper) 


days 


13 


PROJECT  CONSTRAINTS  (MAIN  SOFTWARE  BUILD) 

Cost: _ 

Time: 


8  mos 


People:  7 

Computer:  Severe 


ENVIRONMENT 

Average  Personnel  Skill  Experience 

Overall:  Medium  Similar  Systems:  Medium 

Computer:  Medium  Methodologies:  _ 

Mgmt  Team:  High  Staff  Turnover:  _ 

Response  Time:  5  Minutes  -  1  Hour 


Languages : 
Software  Aids: 


Medium 
High 


Tools  +  Utils:  Good 


Development  Computer:  IBM  3033 

Memory  Occupancy:  _  % 

Real  Time  Code:  0  % 

Requirements  Change:  2  % 


Run  Data:  06-25-1985 
Run  Time:  11:01:01 


PROJECT  DETAIL  REPORT 
Project:  GROSS  MARGIN  ANLYS 


Page :  2 


APPLICATION 

Application  Type:  Business 

System  Features: 

Data  Base  _ 


SYSTEM  DESIGN  COMPLEXITY 

Algorithms  mostly  known  but  logic  designed  from  scratch.  Interfaces  were 
straight  forward. 

CALCULATED  FIELDS 

Productivity  Index:  21  Manpower  Buildup  Index:  6 

Total  Developed,  Delivered,  Executable  Source  Lines  of  Code:  23703 

USER  FIELDS 

1)  _  2}  _ 

3)  USA  4)  HI  CONFID 


PROJECT  DESCRIPTION 

ONLINE  REPORT  REQUESTING  WITH  3  SCREENS  OF  REPORT  SELECTION  CRITERIA  AVAILA3LE 

REPORTS  SHOW  GROSS  MARGIN  INFORMATION  FOR  SEGMENTS  OF  BUSINESS  NIGHT  BATCH  RUN 

FACTORS  THAT  HAD  A  POSITIVE  OR  NEGATIVE  IMPACT  ON  THIS  PROJECT 

-LACK  OF  CLEAR  INFORMATION  ON  DATA  WHICH  IS  USED  TO  GENERATE  REPORTS  LED  TO 
INCORRECT  ASSUMPTIONS  ERRORS  WERE  FOUND  DURING  TESTING  WHICH  CAUSED  THIS  PHASE 

TO  TAKE  LONGER  THAN  PLANNED. 

-ONE  BATCH  PROGRAM  NEEDED  ABNORMALLY  LARGE  TABLE  REDESIGN  NECESSARY  TO  MEET 
PERFORMANCE  CRITERIA 

-TIGHT  SCHEDULE  +USER  PROJECT  MONITOR  DID  A  THROUGH  TESTING  JOB 
+  TEAM  WORKED  AT  NIGHT  TO  GET  ACCEPTABLE  TURNAROUND  ON  THE  CPU  THIS  GOT  THE 
JOB  DONE  BUT  HAD  A  ADVERSE  EFFECT  ON  THE  TEAM  PHYSICALLY 
TOOLS,  UTILITIES,  COMPUTER  BASED  AIDS  &  METHODOLOGIES  USED  ON  THIS  PROJECT 
TOOLS : 

SAS  TEST  &  DEBUG  TOOL 

NATURAL 

ADABASE 

MAYFLOWER  SDM  SYSTEM  DEVELOPMENT  METHODOLOGY 


A 


LIST  OF  BEFEHEHCES 


Putnam, Lawrence  H.  ,  Tutorial  on  Software  Cost 
Estimating  and  L  ife- cycle  "ConTrol  :  Celling  Ine 

software  Numbers .~T~ETE1?~  THO.  " 


Putnam,  Lawrence  H.  ,  Reference  notes  for  the  SLIM 
Software  Cost  Estimati ng  Cour se,~QSM7~T9B5. 


Masters,  Thomas  F.  ,  "Cverview  cf  software  cost  esti¬ 
mating  at  the  National  Security  Agency,"  Journal  of 
International  Society  of  Parametric  Analysts,  7oI.~  5. 
No.~T,~lanT985: -  - - 


Putnam,  Lawrence  H.  ,  SLIM  Users  Manual.  QSM,  1984. 

Boehm,  Barry  W.  .  Software  Engineering  Economics. 
Prentice-Hall,  1981. - — -  - 


Boehm,  Barry  W.  ,  "Software 
IEEE  Transactions  on  Software 
N  o~T,  Jan . T9M7 - - - 


Engineering  Economics." 
Engineering.  Vol  SE-iO 


Fairlry.  Richard  E.  ,  Software  Engineering  Concepts. 
McGraw-Hill,  1985.  - - B — 


Second  Software  Life 
/  8CHT39  0-4C.  TIES  Comp  u 


Cycle 
ter  Socie 


Management 

ty7~T?757 


Workshop , 


Boehm,  B.  W. 
of  Software 
Company,  pp. 


,  "Software  Life  Cycle  Factors,"  Handbook 
Engineering,  Van  Nostrand  EeinnoII 
49JT-518;”T¥§4. 


Stanley,  Margaret,  "Software  Cost  Estimating,"  Journal 
of  International  Society  of  Parametric  AnalystsT  VoT7 
IT,  to .  17  lepiember-!!!^.  ~  ~  ” 


Rome  Air  Development  Center,  1981.  An  Evaluation  of 
S of  twar e^Cost  Estimati  ng  Models,  by  R  .  TliIo<Ieau7 


Wolverton,  R.  w.  ,  "Software  Costing,"  Handbook  of 
Software  Engineering.  Van  Nostrand  RemhoTa~Ccm tany7 
pp.  SF9-4I1,  1WU7 


Bruce  Phillip  and  Pederson,  Sam 
Development  Project  (planning  and 
Filey,  HF2.  - 


M.  ,  The  Software 
JS^nagemenjrr  Conn 
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